The gamma function does not work for complex arguments.
There is a bug in the stdio library for old Sun operating systems (SunOS Sys4-3.2). The ''%g'' format for 'printf' sometimes incorrectly prints numbers (e.g., 200000.0 as ``2''). Thus, tic mark labels may be incorrect on a Sun4 version of GNUPLOT. A work-around is to rescale the data or use the set format command to change the tic mark format to ''%7.0f'' or some other appropriate format. This appears to have been fixed in SunOS 4.0.
Another bug: On a Sun3 under SunOS 4.0, and on Sun4's under Sys4-3.2 and SunOS 4.0, the 'sscanf' routine incorrectly parses ``00 12'' with the format ''%f %f'' and reads 0 and 0 instead of 0 and 12. This affects data input. If the data file contains x coordinates that are zero but are specified like '00', '000', etc, then you will read the wrong y values. Check any data files or upgrade the SunOS. It appears to have been fixed in SunOS 4.1.1.
Microsoft C 5.1 has a nasty bug associated with the %g format for printf. When any of the formats ''%.2g'', ''%.1g'', ''%.0g'', ''%.g'' are used, printf will incorrectly print numbers in the range 1e-4 to 1e-1. Numbers that should be printed in the %e format are incorrectly printed in the %f format, with the wrong number of zeros after the decimal point.
To work around this problem, use the %e or %f formats explicitly.
GNUPLOT, when compiled with Microsoft C, did not work correctly on two VGA displays that were tested. The CGA, EGA and VGA drivers should probably be rewritten to use the Microsoft C graphics library. GNUPLOT compiled with Turbo C uses the Turbo C graphics drivers and does work correctly with VGA displays.
VAX/VMS 4.7 C compiler release 2.4 also has a poorly implemented %g format for printf. The numbers are printed numerically correct, but may not be in the requested format. The K&R second edition says that for the %g format, %e is used if the exponent is less than -4 or greater than or equal to the precision. The VAX uses %e format if the exponent is less than -1. The VAX appears to take no notice of the precision when deciding whether to use %e or %f for numbers less than 1. To work around this problem, use the %e or %f formats explicitly. From the VAX C 2.4 release notes: e,E,f,F,g,G Result will always contain a decimal point. For g and G, trailing zeros will not be removed from the result.
VAX/VMS 5.2 C compiler release 3.0 has a slightly better implemented %g format than release 2.4, but not much. Trailing decimal points are now removed, but trailing zeros are still not removed from %g numbers in exponential format.
ULTRIX X11R3 has a bug that causes the X11 driver to display ``every other'' plot. The bug seems to be fixed in DEC's release of X11R4 so newer releases of ULTRIX don't seem to have the problem. Solutions for older sites include upgrading the X11 libraries (from DEC or direct from MIT) or defining ULTRIX_KLUDGE when compiling the x11.trm file. Note that the kludge is not an ideal fix, however.
The constant HUGE was incorrectly defined in the NeXT OS 2.0 operating system. HUGE should be set to 1e38 in plot.h. This error has been corrected in the 2.1 version of NeXT OS.
Some older models of HP plotters do not have a page eject command 'PG'. The current HPGL driver uses this command in HPGL_reset. This may need to be removed for these plotters. The current PCL5 driver uses HPGL/2 for text as well as graphics. This should be modified to use scalable PCL fonts.
Please report any bugs to bug-gnuplot@ames.arc.nasa.gov.